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© Query optimization by predicate move-around 



© Query optimization which is done by making a 
graph of the query and moving predicates around in 
the graph so that they will be applied early in the 
optimized query generated from the graph. Predi- 
cates are first propagated up from child nodes of the 
graph to parent nodes and then down into different 
child nodes. After the predicates have been moved, 



redundant predicates are detected and removed. 
Predicates are moved through aggregation oper- 
ations and new predicates are deduced from ag- 
gregation operations and from functional dependen- 
cies. The optimization is not dependent on join order 
and works where nodes of the graph cannot 
merged. 
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1 Background of the Invention 

1.1 Field of the Invention 

The invention concerns techniques for con- 
straint propagation generally and more particularly 
concerns techniques for optimizing queries by 
moving constraints so that they are applied as 
early as possible in a computation. 

1.2 Description of the Prior Art 

Data base systems have long been used to 
store and access large quantities of data. The data 
in the data base is organized in some fashion and 
queries made by users of the data base system 
take advantage of the organization of the data base 
to return portions of the data which are useful to 
the user. Many modem data base systems are 
relational data base systems. In such systems, the 
data is organized into a set of relations. Each 
relation is a table which has columns and rows. 
The columns define classes of data (for example, 
employee name, employee department, and pay), 
while the rows contain related values of the data. 
Thus, a us_employee relation might have a row 
for each employee in the U.S. and columns for 
employee name, employee department, and em- 
ployee pay. The specific values in a row for em- 
ployee department and employee pay are the ones 
for the employee specified by the employee name. 
There are two kinds of relations in the data base 
system: base relations in which the data values 
are actually stored in the data base system, and 
views, that is, relations which are not stored, but 
which are constructed on the fly from data in the 
base relations. 

The queries in relational data base systems 
define the data they wish to return in terms of 
relations and constraints on the relations which 
limit what data the query returns from the relation. 
For example, a query on the us_employee relation 
might request a list of the names of all U.S. em- 
ployees whose pay was greater than $100,000 per 
year. The requirement that the employees on the 
list be paid more than $100,000 is of course a 
constraint. 

Most relational data base systems use a lan- 
guage called SQL for their queries. A query in SQL 
for the above example would look like this: 
SELECT name, pay 
FROM us_employees 
WHERE pay> 100,000 

In such a query, the field names of a relation are 
termed attributes of the relation. Thus, in the 
above example, the relation us_employees has 
the attributes name, pay, and dept. A constraint 
which applies to an attribute, for example, the con- 



straint that us_employees.pay>1 00,000 is termed 
a predicate which is applicable to the attribute, in 
this case, the attribute pay. 

Since many data bases are very large, effi- 

5 ciency is an important aspect of the design of data 
base systems. One aspect of efficiency is query 
optimization, which puts the computations needed 
to execute a query into a form which minimizes the 
amount of time and/or memory resources required. 

w An important part of query optimization is optimiz- 
ing the application of constraints. Two techniques 
for optimizing constraints are minimizing the num- 
ber of constraints and applying them as early as 
possible. 

75 For instance, if we expand the previous exam- 
ple to include another relation, world_employees, 
in which the rows have the same attributes as the 
rows in us_employees and apply our query to 
both relations, we get: 

20 SELECT name, pay 

FROM us_employees, world_employees 
WHERE pay>100,000 

There are two ways of computing this query: one 
way is to assemble all of the rows from both 

25 relations and then apply the predicate 
pay>1 00,000; the other is to apply the predicate in 
each relation and only assemble the rows from 
each relation which satisfy the predicate. Clearly, 
the second way saves the time required to copy 

30 the rows which do not satisfy the predicate and the 
space required to store all of the rows from both 
relations, and is consequently more efficient. The 
second way is thus an optimization. In this case, 
the optimization is achieved by applying the predi- 

35 cate in each relation, so that it is applied as early 
as possible in the computation. 

A number of techniques are known for applying 
predicates as early as possible. These techniques 
are commonly termed predicate pushdown tech- 

40 niques. The techniques are applied to a query 
graph, a data structure which represents the query 
during optimization. In the query graph for a query, 
each of the query's subqueries and views forms a 
block of the graph. One of the techniques is merg- 

45 ing query blocks, as explained in H. Pirahesh, J. 
Hellerstein, and W. Hasan, "Extensible/rule based 
query rewrite optimization in starburst", in SIGMOD 
1992, pp. 39-48. This technique is limited by the 
fact that query blocks often cannot be merged. 

50 Another of the techniques is pushing predicates 
down the query graph, into query blocks that are 
computed earlier during evaluation. This technique 
works only on hierarchical queries, that is, queries 
which are nonrecursive and do not have common 

65 subexpressions. See J. Ullman, Principles of 
Database and Knowledgebase Systems, vol. 1 
and 2, Computer Science Press, 1989. A third 
technique is based on the magic set transforma- 
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tion, explained in the Ullman text. The third tech- 
nique permits a predicate to be moved up from a 
relation and down into another relation when the 
other relation appears later in the join order, as 
explained in detail in I. Mumick, S. Rnkelstein, H. 
Pirahesh, and R. Ramakrishnan, "Magic Condi- 
tions", in PODS 1 990. 

What is needed, and what is provided by the 
present invention, is an optimization technique 
which permits predicates generally to be moved 
around a query tree to the node where their ap- 
plication is most efficient and applying them in that 
node. 

2 Summary of the Invention 

The optimization technique is a generalization of 
the predicate-pushdown technique, called predi- 
cate move- around, which first moves predicates 
into other nodes of the query graph and then 
reduces the number of the propagated predicates. 
As a result, each predicate is applied at an ad- 
vantageous point in the computation of the query. 
In a preferred embodiment, the predicates are 
moved by propagating them up the query graph 
and then down the query graph and the reduction 
removes redundant predicates. At the end of the 
reduction, the remaining predicates are applied as 
early as possible in the computation. 

Predicate move-around can be applied even if 
some blocks have aggregates and even if du- 
plicates are retained in some blocks and eliminated 
in others. Our algorithm for predicate move-around 
is extensible in the sense that (1) a variety of 
predicates can be moved around; for example, 
comparison and inequality predicates, EXISTS and 
NOT EXISTS predicates, negated base relations 
(the EXCEPT clause), arithmetic predicates (e.g., X 
= Y + 2), the LIKE predicate, functional depen- 
dencies and more, and (2) Predicates can be 
moved through new operators like outer-join. The 
predicate move-around results in applying a larger 
number of predicates to base and intermediate 
relations and doing so as early as possible; hence, 
the evaluation becomes much more efficient. Un- 
like the magic-set transformation, predicate move- 
around does not need auxiliary relations (such as 
the magic and supplementary relations) and does 
not depend upon the order of doing joins. Our 
move-around algorithm applies to nonrecursive 
SQL queries, including SQL queries with correla- 
tions. It can also be generalized to recursive SQL 
queries. 

Our technique includes the following novel fea- 
tures: 

• Moving predicates up, down and sideways in 
the query graph, across query blocks that 
cannot be merged. 



• Moving predicates through aggregation; in 
the process, new predicates are deduced 
from aggregation. 

■ Using functional dependencies to deduce and 
5 move predicates. 

■ Moving EXISTS and NOT EXISTS predicates. 
The EXCEPT clause can also lead to a NOT 
EXISTS predicates that can then be moved. 

• Removing redundant predicates. This is im- 
70 portant, since redundant predicates can lead 

to incorrect selectivity estimates that may 
result in access paths and join methods that 
are far from optimal. Moreover, redundant 
predicates represent wasted computation. 
75 Our technique can be easily combined with exist- 
ing query optimizers, since it works by rewriting 
the original queries and views. 

Other objects and advantages of the apparatus 
and methods disclosed herein will be apparent to 
20 those of ordinary skill in the art upon perusal of the 
following Drawing and Detailed Description, 
wherein: 

3 Brief Description of the Drawing 

25 

FIG. 1 is a set of example relations and views; 
FIG. 2 is an optimized version of the relations 
and views of FIG. 1 ; 

FIG. 3 shows subnodes in a GROUPBY node; 
30 FIG. 4 shows the structure of a UNION or IN- 
TERSECTION node; 

FIG. 5 Is an example of a query tree during 
optimization; 

FIG. 6 is the query tree of FIG. 5 after optimiz- 
35 ation; and 

FIG. 7 shows the base relations used in the 
example. 

Reference numbers in the Drawing have two parts: 
the two least-significant digits are the number of an 
40 item in a figure; the remaining digits are the num- 
ber of the figure in which the item first appears. 
Thus, an item with the reference number 201 first 
appears in FIG. 2. 

45 4 Detailed Description of a Preferred Embodi- 
ment 

The Detailed Description is organized as follows. 
Section ?? illustrates the savings achieved by 

so predicate move-around via a detailed example. 
Section ?? describes the SQL syntax and the que- 
ry-tree representation on which the algorithm op- 
erates. The query tree is a straightforward parse 
tree representation of a query, close to what is 

55 used in several systems (e.g., H. Pirahesh, J. Hel- 
lerstein, and W. Hasan. "Extensible/rule based que- 
ry rewrite optimization in starburst", in SIGMOD 
1992, pages 39-48. The predicate move-around 
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algorithm is detailed in Section ??. We describe 
the general algorithm, and illustrate each step of 
the algorithm on the example of Section ??. 

4.1 Illustrative Example 

We consider a detailed example that illustrates the 
benefits of the predicate move-around optimization. 
In particular, this example illustrates how predicates 
can be moved across query blocks, through ag- 
gregation and using knowledge about functional 
dependencies. 

This example is representative of the complex- 
ities to be found in real world decision-support 
queries. Further, it illustrates our algorithm's in- 
creased ability to deal with complex queries. The 
example uses the base relations from a telephone 
database shown in FIG. 7. calls relation 703 has a 
tuple (row) for every call made. A telephone num- 
ber is represented by the area code (AC) and the 
local telephone number (Tel). Foreign numbers are 
given the area code "011." A call tuple contains 
the telephone number from which the call is 
placed,, the telephone number to which the call is 
placed, and the access code used to place the call 
(0 if an access code is not used). The starting time 
of the call, with a granularity of 1 minute, and the 
length of the call, again with 1 minute granularity, 
are included. Due to the time granularity and mul- 
tiple lines having the same phone number, du- 
plicates are permitted in this relation. In particular, 
there can be several calls of 1 minute each starting 
within the same 1 minute, and there can be mul- 
tiple calls running concurrently between two given 
numbers. 

customers relation 705 gives information about 
the owner of each telephone number. The informa- 
tion about owners consists of the owner's name, 
his account type (Government, Business, or Per- 
sonal), and his membership level (Basic, Silver, or 
Gold). The key (i.e., the attribute values used to 
access the row) of the customers relation is {AC, 
Tel} and, so, the following functional dependency 
holds: 

{AC, Tel} -* {OwnerName, Type, MemLevel}. 
That is, given AC and Tel, the system can retrieve 
the values of the other attributes. 

A telephone number can have one or more 
users that are listed in users relation 707. Each 
user of a telephone number may have an access 
code. One user may have multiple access codes, 
and one access code may be given to multiple 
people. There are no duplicates in the users rela- 
tion. 

A few telephone numbers have been declared 
secret, as given by secret relation 709. 

promotion relation 711 has, for each planned 
marketing promotion, the name of the sponsoring 



organization, the area codes to which calls are 
being promoted, and the starting and ending dates 
of the promotion. Note that there may be several 
tuples with the same area code and same sponsor, 
5 but with different dates. 

Example 4.1 In the following, a query 01 will be 
optimized by moving predicates around. FIG. 1 
shows query Q1 107 and the relations which define 
it. The base relations 701 are those of FIG. 7. 
io Those relations are then used to define two views. 
View fgAccounts 103, denoted as £1, lists all for- 
eign accounts (i.e., Area-Code = "01 1 ") of type 
"Govt" that are not secret accounts. View 103 
includes telephone numbers and names of users of 
75 those numbers. 

The second view ptCustomers 107 (i.e., poten- 
tial customers), denoted as F1, first selects calls 
longer than 2 minutes and then finds, for each 
customer with a silver level membership, the maxi- 
20 mum length amongst all his calls to each area 
code other than the customer's own area code. 

Query 01 107 is then defined in terms of 
fgAccounts 103 and ptCustomers 107. Query 107 
has been posed by a marketing agency looking for 
25 potential customers among foreign governments 
that make calls longer than 50 minutes to area 
codes in which some promotion is planned. The 
query lists the phone number of each relevant 
foreign government, the names of all users of that 
30 phone and the names of the sponsors of the rel- 
evant promotions. Note that duplicates are retained, 
since sponsors may have one or more promotions 
in one or more area codes. 

Ordinary query optimizers cannot deal effec- 
35 tively with query 01 107 because neither view £1 
103 nor view F1 107 can be merged into the query 
block of 01 107. One reason for this is that view 
ptCustomers 105 does aggregation, that is, it pro- 
vides one or more results whose computation in- 
40 volves more than one tuple of the relation. In 
ptCustomers, the aggregation operation is specified 
by GROUPBY. Another reason why the views can- 
not be merged is that the view fgAccounts 103 
generates and eliminates duplicates (while 01 107 
45 retains duplicates). 

Since no merger is possible, an ordinary opti- 
mizer is forced to optimize and evaluate each view 
separately and then optimize and evaluate the que- 
ry. In particular, such an optimizer cannot push the 
50 predicate MaxLen > 50 of 01 107 from the defini- 
tion of Q1 into the definition of the view 
ptCustomers 105 (since that predicate is over a 
field that is aggregated in ptCustomers). Thus, 
when evaluating the view ptCustomers 105, we can 
55 only use the predicate Length > 2; later, when 
evaluating query 01 105, we can use the predicate 
MaxLen > 50 to discard those ptCustomers tuples 
that do not satisfy this selection. 



4 



7 



EP 0 689 148 A1 



Our optimization algorithm, in comparison, will 
do much better, since it is capable of the following: 

• Taking the predicate c.AC = "011" of the 
view fgAccounts 103 and moving it into the 
view ptCustomers 105. As a result, the join 
predicate c.AC = t.FromAC is replaced with 
t.FromAC = "011" and t.ToAC <> t.FromAC 
is replaced with t.FromAC <> "011". 

• Taking the predicate c.Type = "Govt" from 
the view fgAccounts 103 and moving it into 
the view ptCustomers 1 05, where it is applied 
to customers relation 705. Note that deter- 
mining, the soundness of this move requires 
that we reason with knowledge about func- 
tional dependencies (explained in detail 
later). Specifically, in query Q1 107, the 
views fgAccounts 103 and ptCustomers 105 
are joined on a key of the customers relation 
and, therefore, the predicate c.Type = 
"Govt" can be moved from fgAccounts into 
the definition of ptCustomers. 

• Taking the predicate 

NOT EXISTS (SELECT * FROM secret s 
WHERE s.AC = c.FromAC AND 
s.Tel = c.FromTel) 
from the view fgAccounts and moving it into 
the view ptCustomers. This leads to . a more 
efficient evaluation of the view ptCustomers, 
since the customers relation can be restricted 
before taking the join with calls and before 
the grouping operation. 

• Taking the predicate c.MemLevel = "Silver" 
from the view ptCustomers and moving it into 
the view fgAccounts. Again, functional depen- 
dencies are used for this move. 

• Taking the predicate MaxLen > 50 from the 
query and inferring that tLength > 50 can be 
introduced in the WHERE clause of 
ptCustomers. As a result, the predicate 
tLength > 2 can be eliminated from the defi- 
nition of ptCustomers and the predicate 
tLength > 50 can be deleted from the query. 
Note that this optimization amounts to push- 
ing a selection through aggregation, a novel 
feature of our algorithm. 

The optimized views and query are denoted in 
Figure 2 as E1 0 203, Flo 205, and Q1 0 207. 
Section ?? explains the behavior of the move- 
around algorithm on this example in detail. □ 

4.2 Preliminaries: SQL Notation and the Query- 
Tree Representation 



section we briefly describe the SQL syntax and 
explain how to build the query tree. 

4.3 SQL Syntax 

An SQL query can be viewed as a sequence of 
view definitions, one of which is designated as the 
query view. A view definition can be a single SE- 
LECT statement, of the form 
w (V): CREATE VIEW ... AS 

SELECT ... 

FROM ... 

WHERE... 

GROUPBY ... 
75 HAVING ... 

where the GROUPBY and HAVING clauses are 
optional. Alternatively, a view may be defined as a 
UNION, INTERSECTION, and EXCEPT of multiple 
SELECT statements. 

4.3.1 The Query Tree 

Each node of a query tree corresponds to a step in 
the evaluation of an SQL query. A step is the 

25 computation of either a SELECT block (i.e., a SE- 
LECT-FROM-WHERE clause), a GROUPBY block - 
(i.e., a SELECT block combined with GROUPBY 
and HAVING clauses), The root of the tree is the 
query view. The children of a node n are the views 

30 (i.e., non-base relation) referenced in the computa- 
tion of n. For example, a node for a SELECT block 
has a child for every view referenced in the FROM 
clause of that block. 

Local and Exported Attributes: Each computa- 

35 tion step has some operands and a result. The 
local attributes of a node are those appearing in 
the operands; in example 101, local attributes are 
given the reference number 109. The exported 
attributes are those appearing in the result; in 

40 example 101, they have the reference number 111. 
Note that the exported attributes of a node n are 
some of the local attributes of the parent of n. Also 
note that root 503 of tree 501 (i.e., the node for the 
query view) does not have exported attributes. 

45 Labels: In tree 501, each node n has an asso- 
ciated label 511 that eventually contains all the 
predicates 513 applicable to local and exported 
attributes of n. Due to functional dependencies, 
labels may also contain functional terms. An exam- 

50 pie of such a functional term in label 51 1 of Fig. 5 

is c Type = f 1 (c.Ac.c.Tel), where the value of 

c.Type is returned by the functional term f_1- 
(c.Ac,c.Tel). 



The predicate move-around algorithm works on a 

query-tree representation of the SQL query. A que- 55 4.4 Kinds of Nodes in a Query Tree 
ry tree is essentially a parse tree of the query. The 

query tree for the example of FIG. 1 is shown in The query tree 501 of a preferred embodiment 

FIG. 5 and will be discussed in detail later. In this may be up of four kinds of nodes: SELECT nodes, 
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GROUPBY nodes, UNION nodes, and INTERSEC- 
TION nodes. 

SELECT Nodes 

When a view definition consists of a single SE- 
LECT block (i.e., a SELECT-FROM-WHERE 
clause) of the form 
CREATE VIEW V(*i A!} AS 

SELECT r, .B, r,.B, 

FROM ReU r, Rel m r m 

WHERE ... 

we create a SELECT node n. In query tree 501, 
there are three SELECT nodes: 507, 517, and 503. 
The local attributes of a SELECT node n are all the 
attributes used in its computation, i.e. terms of the 
form r,.S, where 1 S / S m and B is an attribute of 
Rel,. For example, in SELECT node 507, the local 
attributes are C.AC, C.Tel, C.Type, u.AC, and u.Tel. 

The exported attributes are V.Ai V.A,, or in the 

case of node 507, AC, Tel, UserName. Note that 
the exported attributes are just aliases of the local 
attributes listed in the SELECT clause. If Rel, is 
also a view, then n has a child node for the 
definition of Rel,. A SELECT DISTINCT block is 
treated in exactly the same way as a SELECT 
block. (The difference between SELECT and SE- 
LECT DISTINCT is that in SELECT DISTINCT, 
duplicates are not selected.) 

GROUPBY Triplets and Nodes 

A view definition consisting of a GROUPBY block 
may be dealt with in the present discussion as if it 
were separated into three nodes. GROUPBY triplet 
301 is shown in FIG. 3. The bottom node, rti 303, 
is a SELECT node for the SELECT-FROM-WHERE 
part of the view definition (it may have children as 
described above for SELECT nodes). The middle 
node', n 2 305, is a GROUPBY node and it stands 
for the GROUPBY clause and the associated ag- 
gregations. The top node, n 3 307, is a HAVING 
node and it stands for the predicates in the HAV- 
ING clause. 

Let L denote the set of local attributes in rti 
303 (defined as for an ordinary SELECT node) and 
let A denote the set of aggregate terms (e.g., Max- 
(r.D)) from the SELECT clause. In both m 303 and 
n 2 307, L is the set of local attributes, while L u A 
is the set of local attributes in n 3 . The set of 
exported attributes in /?, 305 is L, in n 2 it is L u A 

and in n 3 it is {V.A, V.A,}. Thus, in FIG. 5, 

where node 505 consists of a SELECT node 517 
and a GROUPBY node 515, the local and exported 
attributes of node 517 and the local attributes of 
node JJ2 are t.Length, t.ToAC, t.FromAc, tc.Tel, 
cMemLevel, c.Type, c.AC, s.Tel, and s.AC. The 
exported attributes of node 515 are c.AC, c.Tel, 



c.ownerName, LToAC, and MAX (t.length). 

A view definition may have aggregation in the 
SELECT clause even without having GROUPBY 
and HAVING clauses. In this case, it should be 

5 considered as having an empty GROUPBY clause. 
Also note that if there is only a GROUPBY clause 
(and no HAVING clause), then we can omit the top 
node n 3 307, as in query tree 501, and let V.Ai 
V.A, be the exported attributes of /fe 305; in this 

10 case, the attributes of A are considered local in n 2 
305. 

UNION and INTERSECTION Nodes 

75 if a view definition includes UNION (or INTERSEC- 
TION), we create a node n 403 for this operation as 
shown in FIG. 4. Node n has a SELECT child 4050) 
for every SELECT block- in the view definition. For 
the /* SELECT child 405, the local attributes are 

20 defined as usual and the exported attributes are 

V h A-\ V,A where V, is a newly created name. 

The local attributes of (UNION or INTERSECTION) 
node n 403 are the exported attributes from all its 
children. The exported attributes of node n 403 are 

25 VA\ V.A,. Note that some of the SELECT 

blocks of the view definitions may contain 
GROUPBY blocks, and therefore, some children of 
n may be triplets 301 , as described above. 

30 DAG Queries 

If some view V is referenced in two different views 
(i.e., the node representing V may have more than 
one parent), the query graph is a directed acyclic 

35 graph, or DAG. In that case, the DAG must be 
converted to a tree by duplicating V (and its chil- 
dren) in the query tree. After completing the two 
phases of the algorithm, we can combine the two 
occurrences of V into a common subexpression. 

40 However, if the two occurrences end up with two 
distinct labels, we may not want to combine them, 
as discussed in Section ??. 
Example 4.2 FIG. 5 shows query tree 501 for 
query Q1 107 of FIG. 1 The view ptCustomers 105 

45 is represented on the left by a SELECT node 517 
and a GROUPBY node which are combined in the 
doublet 505. The view fgAccounts 103 is repre- 
sented on the right by a single SELECT node 507. 
Query view Q1 10 itself is represented by a single 

50 SELECT node 503 at the top. The arcs 519 and 
521 from ptCustomers node 505 and fgAccounts 
node 507 respectively into query node 503 arise 
from the usage of the views in defining the query. 
Query tree 501 also shows the labels which have 

55 been added to the nodes after completion of the 
initialization and pullup phases of predicate move- 
around. The predicates in normal font were added 
to the labels during initialization (for example, the 
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predicates at 511 in Fig. 5). The predicates in bold 
font were added to the labels in the pullup phase 
(for example, the predicates at 509). □ 

5 The Move-Around Algorithm 

We give an overview of the main steps of the 
predicate move-around algorithm, followed by a 
detailed description of each step. 

5.1 The Main Steps of the Algorithm 

1. Label initialization: Initial labels are created 
from the predicates in the WHERE and HAVING 
clauses and from functional dependencies. (Ini- 
tial labels refer only to local attributes.) 

2. Predicate pullup: The tree is traversed bot- 
tom-up. At each node, we infer predicates on 
the exported attributes from predicates on the 
local attributes and push the inferred predicates 
to the parent node. 

3. Predicate pushdown: The tree is traversed 
top-down. At each node, we infer predicates on 
the local attributes from predicates on the ex- 
ported attributes and push the inferred predi- 
cates to the children of that node. 

4. Label minimization: A predicate can be re- 
moved from a node if it is already applied at a 
descendant of that node. 

5. (Optional:) Convert the query tree into SQL 
code (the plan optimizer may also work directly 
with the tree representation of the query). 

As a result of the above algorithm, the predi- 
cates are propagated to every node of the query 
tree where they can be applied and duplicates are 
removed so that there are fewer predicates in the 
tree and those remaining are located at an advanta- 
geous position in the query tree for the computa- 
tion of the query. In a preferred embodiment, the 
advantageous position is as low in the query tree 
as possible; however, in other embodiments, other 
techniques for determining advantageous positions 
may be applied as well. 

The algorithm is extensible in the sense that ft 
can be extended to new types of predicates (e.g., 
LIKE) and to new types of nodes (e.g., outer-join). 
Next, we explain each step in detail. 

5.2 Label Initialization 

SELECT Nodes: The initial label of a SELECT 
node consists of the predicates appearing in the 
WHERE clause. For example, in FIG. 5, the first 
five predicates 523 in fgAccounts node 507 come 
from the WHERE clause. Note that (NOT secret- 
(cAC, c.Tel)) is simply a shorthand for the NOT 
EXISTS subquery. 

GROUPBY Triplets: In a node triplet 301 for a 



GROUPBY block (see FIG. 3), the initial labels of 
the bottom node 303 and top node 307 are the 
predicates from the WHERE and HAVING clauses, 
respectively. The initial label of middle node n 2 305 
s includes predicates stating that the grouping at- 
tributes functionally determine the aggregated val- 
ues. For example, in the view ptCustomers 105, the 
predicate 

MaxLen = f 3(c.AC, c.Tel, c.OwnerName, 

w t.ToAC) 

appears in GROUPBY node 515. 
UNION and INTERSECTION nodes: The initial 
label of a UNION or an INTERSECTION node n 
403 is empty. 

15 Functional Dependencies: Suppose that the fol- 
lowing functional dependency holds in a base rela- 
tion ft. 

A k ) —■ {Si ,...,S P } 

If a WHERE or a HAVING clause refers to ft, then 
20 the predicates 

ffd i (r.A 1 ,...,r.A k ) = 



B{ (1 < i < p) 

are added to the label created for that clause. For 
30 example, the functional dependency 

{AC, Tel} — {OwnerName, Type, Mem Level} 
holds in customers relation 705; hence, the predi- 
cate 

c.Type = f_1(c.AC, c.Tel) 

35 is added to SELECT nodes 507 and 517, since 
both reference customers relation 705. 
Equality Predicates: If, in node n, two exported 
attributes, VA, and VA,, are aliases of the same 
local attribute, then add the equality VA/ = V.Aj to 

40 the label of n. 

Example 5.1 The initial labels for query tree 501 
are shown in typewriter font. □ 

5.3 Predicate Pullup 

45 

In the predicate-pullup phase, we traverse the tree 
bottom up, starting from the leaves. At each node, 
we infer predicates on the exported attributes from 
predicates on the local attributes. The inferred 
50 predicates are added to the labels of both the 
given node and its parent. The particular method 
for inferring additional predicates depends on the 
type of node under consideration and the types of 
predicates in the label of that node. 

55 
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5.3.1 Predicate pullup through SELECT nodes 

To pull up predicates through a SELECT node n, 
having a label L{n), we proceed as follows. 

• Add to L(n) new predicates that are implied 
by those already in L(n). For example, if both 
n.A < r 2 .B and r 2 .B < r 3 .C are in L{n), then 
r u A < h.C is added to L{n). Ideally, we 
would like to compute the closure of L(n) 
under logical implications, since that would 
maximize the effect of moving predicates ar- 
ound. However, the move-around algorithm 
remains sound even if we are not able to 
compute the full closure. Note that when 
predicates consists only of conjunctions of 
comparisons (i.e., <, ^, <> and =) among 
constants and ordinary attributes (i.e., no ag- 
gregate terms), then the closure can be com- 
puted in polynomial time. See the Ullman 
reference above. 

■ Infer predicates with exported attributes as 
follows. If a is in L{n), then add r(a) to L(n), 
where t substitutes the exported attributes for 
the local attributes. For example, in fgAc- 
counts node 507, the predicate fgAc- 
counts.AC = "01 1" on the exported at- 
tributes is inferred from the predicate c.AC = 
"01 1 " on the local attributes. 

• If a predicate in L(n) refers only to exported 
attributes or constants, then add that predi- 
cate to the label of the parent of n. In FIG. 5, 
for example, the predicate fg.AC = "01 1 " is 
added to the label of the root. 

Example 5.2 In Fig. 5, the labels generated by the 
pullup phase are shown in bold font, for example, 
at 509. For clarity, the label of the GROUPBY node 
does not show the predicates pulled up from its 
child. Also, we do not show all the predicates in the 
closures of labels. □ 

5.3.2 Predicate pullup through GROUPBY tri- 
plets 

In principle, it is enough to perform the three steps 
of the previous section at each node of a 
GROUPBY triplets (starting with the bottom node). 
Note that the middle step is redundant in the 
bottom and middle nodes, since all local attributes 
in these two nodes are also exported attributes. In 
practice, however, we need some rules for inferring 
predicates involving aggregate terms. Following is 
a (sound but not complete) set of such rules; these 
rules should be applied to the label, L(n 2 ), of the 
middle node (in all these rules, £ can be replaced 
with <). 

1. If Min(B) is an attribute of n 2 (i.e., Min(B) 
appears in the SELECT clause), then add Mln(B) 
Z B to L(n 2 ) (in words, the minimum value of B 



is less than or equal to every value in column 
B). Furthermore, if (Bk c) e Lfa), where c is a 
constant, then add Min{B) icto /.(Ate) (in words, 
if c is less than or equal to every value in 
5 column B, then c is also less than or equal to 
the minimum value of S). 

2. If Max(B) is an attribute of n 2 , then add Max- 
(B)t B to L(n 2 ). Furthermore, if (B £ c) <= /-(rfe), 
where c is a constant, then add Max(B) icto L- 

10 (n 2 ). For example, consider GROUPBY node 
515 in FIG. 5. First, we infer Max(t.Length) =s 
tLength. Since t.Length > 2 is pulled up from 
node 517, we infer Max(t.Length) > 2 (by transi- 
tivity). Now, MaxLen > 2 is inferred, since Max- 

75 Len is an exported attribute that is an alias of 
Max(t.Length). For clarity, only MaxLen > 2 is 
shown in the figure. 

3. Consider the following three predicates: Max- 
(B) £ Min{B), Avg(B) Z Min{B) and Max(B) k 

20 Avg(B). Each of these predicates is added to L- 
(n 2 ) if its aggregate terms are attributes of n 2 . 

4. If Avg(B) is an attribute of rfc and (B£ c)e L- 
(n 2 ), where c is a constant, then add Avg(B) & c 
to L(n 2 ). If (fl £ c) e L(n 2 ), then add (Avg(B) £ c) 

25 to L(n 2 ). 

5.3.3 Predicate pullup through UNION and IN- 
TERSECTION nodes 

30 Consider a UNION (or INTERSECTION) node n, as 
shown in FIG. 4. Recall that the exported attributes 

of node n are V.Ai V.A k while the exported 

attributes of the I th SELECT child are V,.Ai V,.A h 

where V, is a newly created name. 

35 Suppose that D f is a conjunction of predicates 
that have been pulled up into node n from its i* 
SELECT child, and let D, be obtained from D-, by 
substituting V.A;for V,.A; (1 S j£ I). If A) is a UNION 
node, we add Di V...V D m to the labels of both n 

40 and its parent. If n is an INTERSECTION node, we 
add D\ A.. .A O m to the labels of both n and its 
parent. 

5.4 Predicate Pushdown 

45 

This phase of the algorithm is a generalization of 
predicate-pushdown techniques. The combination 
of pullup and pushdown effectively enables us to 
move predicates from one part of the tree to other 

50 parts. In this phase, we traverse the query tree top 
down, starting from the root. At each node, we infer 
new predicates on the local attributes from predi- 
cates on the exported attributes and push the in- 
ferred predicates down into the children nodes. As 

55 earlier, the pushdown process depends on the type 
of the node. The result of the push-down process 
in the query tree for FIG. 1 is shown in query tree 
601 of FIG. 6. 



15 



EP 0 689 148 A1 



16 



5.4.1 Predicate pushdown through SELECT 
nodes 

In a SELECT node n, with label L(n), we do as 
follows. 

• Infer new predicates over the local attributes 
as follows. For each predicate a in L(n), add 
t -1 («) to L(n) (if it is not already there), where 
t -1 substitutes local variables for the export- 
ed variables. 

• Add to L(n) new predicates that are implied 
by those already in L(n). 

• For each child n, of n, add to L{ru) all 
predicates of L(n) having only exported at- 
tributes of n-i or constants. 

Example 5.3 In query tree 601, the predicate 
ptcMaxLen > 50 is pushed from root node 603 into 
GROUPBY node 613; predicates added during the 
pushdown phase are shown in italic in query tree 
601 . For clarity, we do not show the full closure at 
each node. 
□ ■ 

5.4.2 Predicate pushdown through GROUPBY 
triplets 

The three steps set forth for SELECT nodes should 
also be performed at the nodes of a GROUPBY 
triplet 301. However, we also need rules for infer- 
ring new predicates from predicates with aggregate 
terms. Following is a set of such rules; the rules 
should be applied to the label, L{Th), of middle 
node 305 (in all these rules, S can be replaced with 
<)■ 

• Suppose that Max{B) Z c is in /.(/fe), where c 
is a constant. If Max(B) is the only aggregate 
term in nz, then we can add B £ c to L(nz). 
Obviously, looking just at tuples satisfying B 
i c is sufficient for computing Max(B), given 
that Max(B) should satisfy Max(B) £ c. Gen- 
erally, however, we cannot look just at tuples 
satisfying £ s c in order to compute other 
aggregates. For that reason we require that 
Max(B) be the only aggregate term in rfe. 
Consider, for example, GROUPBY node 613 
in FIG. 6. The predicate MaxLen > 50 is 
pushed into node 613 from root node 603. By 
translation into local attributes, we get Max- 
(tlength) > 50. Since Max(t.length) is the only 
aggregate term in GROUPBY node 613, we 
can infer the predicate t.length > 50. Note 
that by pushing t.length > 50 down, we dis- 
cover that we only need tuples satisfying 
t.length > 50 in view ptCustomers 705, be- 
cause the maximum of t.length should be 
greater than 50. 

• If Min(B) £ c is in L{nz), where c is a con- 
stant, and Min(B) is the only aggregate term 



in nz, then we can add B S c to L(ni). 

5.4.3 Predicate pushdown through UNION and 
INTERSECTION nodes 

5 

Consider a UNION (or INTERSECTION) node n 
403, as shown in FIG. 4. Let t,- denote the substitu- 
tion of the exported attributes of the f SELECT 
child 405 of n 403 for the exported attributes of n; 

10 that is, t/ substitutes V,.Ai V,.A, for V.Ai V.A t . 

The pushdown of predicates from n into its 
children is done as follows. If a is in L(n) and all 
attributes in a are exported attributes of n, then add 
T,<a) to the label of the P SELECT child 405 of n 

15 403 (note that there is no need to add Tj(a) to the 
label of n, even if it is not there). 
Example 5.4 In FIG. 6, the labels generated by the 
push-down phase of the algorithm are shown In 
italic font, indicated by 609. □ 

20 

5.5 Label Minimization 

At the end of the top-down phase, the same predi- 
cates may be repeated in many nodes of the tree. 
25 As a result, we can apply predicates earlier than 
was possible in the original tree. There is the posf5 
In fact, even an evaluation of the original tree could 
result in redundant applications of predicates; this 
may happen, for example, when the original query 
30 is formulated using predefined views and the user 
is oblivious to the exact predicates that are used in 
those views (and, hence, he may redundantly re- 
peat the same predicates in the query). In the 
move-around algorithm, redundancies are intro- 
35 duced in two ways. 

• As a result of translation from local to ex- 
ported attributes (or vice versa) and the asso- 
ciated pullup (or pushdown), the same predi- 
cate appears in some node and in the parent 
40 of that node (and, possibly, also in some 

other ancestors of that node). There is no 
need, however, to apply a predicate at a 
node if it has already been applied at a 
descendant of that node. 
45 when adding predicates that are logically im- 

plied by existing ones. 
Removing redundancies is important for two 
reasons. First, it saves time, since fewer tests are 
applied during the evaluation of the query. See- 
so ondly, redundant predicates might mislead the plan 
optimizer due to incorrect selectivity estimates. 

Redundancies of the first kind are removed as 
follows. Suppose that predicate a appears in node 
n and all attributes of a are local to n, but also 
55 have aliases among the exported attributes of n. 
Then a predicate 0 in the parent of n is redundant 
if 0 is logically implied by t{«), where r substitutes 
the exported attributes of n for the local ones. 
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Redundancies of the second kind are removed 
by the known technique of transitive reduction; 
that is, we repeatedly remove a predicate from a 
label if it is implied by the rest of the predicates. 
We get a nonredundant label when no more predi- 
cates can be removed. 

Finally, we can completely remove labels of 
GROUPBY, UNION and INTERSECTION nodes. 
Moreover, predicates containing functional terms 
(that were generated from functional dependencies 
and aggregations) are also dropped from all nodes. 
In FIG. 6, the predicates annotated with a star 611 
remain after minimization and form the final labels 
in our example. 

5.6 Translating the Query Tree to SQL 

The query tree may be used directly for further 
rewrite and cost-based optimizations as well as 
evaluation of the query. In fact, the query tree is 
similar to the internal representations of queries 
used by some existing query processors. If de- 
sired, however, we can easily translate the query 
tree back into SQL as follows. SELECT, UNION 
and INTERSECTION nodes, and GROUPBY triplets 
are translated into the appropriate SQL statements; 
the WHERE and HAVING clauses consist of the 
minimal labels of the corresponding nodes. In our 
example, the optimized SQL query and views 201 
of FIG. 2 are the result of applying the above 
translation to query tree 601 of FIG. 6. 

5.6.1 Translating DAG Queries 

When a query tree is created from a DAG query, 
several subtrees of the tree may correspond to the 
same view. These subtrees are identical at the 
beginning of the move-around algorithm, but may 
become different at the end of the algorithm. Con- 
sider two subtree, 7"i and T2, generated from the 
same view V. If, at the end of the algorithm, 7i and 
7 2 are equivalent, then it is sufficient to evaluate 
just one of K and T2. If 7i is contained in T 2 (i.e., 
each label of 7"i logically implies the label of the 
corresponding node of Tz), then the view for T2 
can be computed from the view for K by applying 
the appropriate selection If neither one is contained 
in the other, it may still be possible to compute one 
view from which the two views can be obtained by 
additional selections. 

6 Conclusion 



ing the query and then reduced. 

In a preferred embodiment, the predicates are 
pulled up.i.e. propagated into ancestor nodes of the 
nodes originally containing the predicates and then 

5 pushed down, i.e. propagated into descendent 
nodes which are different from the nodes which 
originally contained the predicates. The number of 
the propagated and unpropagated predicates is 
then reduced so that there are fewer predicates 

10 and each predicate is in a location in the query tree 
which is advantageous for the computation. One 
such location is as far down the query graph as 
possible. 

The disclosed techniques may be used in situ- 

15 ations where optimization by merging blocks or by 
means of magic sets transformations are not possi- 
ble, and may also be combined with these and 
other query optimization techniques. Portions of the 
disclosed techniques, including propagating the 

20 predicates first up and then down the query graph, 
moving predicates through aggregation, using func- 
tional dependencies to deduce and move predi- 
cates, moving EXISTS and NOT EXISTS predi- 
cates, and removing redundant predicates, may be 

25 employed independently of the predicate move- 
around techniques. 

While the embodiment of the "Detailed De- 
scription" employs a relational database accessed 
by SQL queries, the technique can be used in any 

30 system in which a query is applied to data and the 
query can be parsed to produce a directed acyclic 
graph. Techniques other than those disclosed here- 
in may be used to move predicates around the 
query graph and to reduce the predicates. For 

35 example, in some cases, it is more efficient to 
apply a predicate later in the computation, and 
other embodiments of the invention can incorporate 
tests for such predicates in their predicate reduc- 
tion phase. What algorithms are in fact used to 

40 move predicates and reduce them may of course 
depend on the kind of system being optimized. 

All of the above being the case, the foregoing 
Detailed Description is to be understood as being 
in every respect illustrative and exemplary, but not 

45 restrictive, and the scope of the invention disclosed 
herein is not to be determined from the Detailed 
Description, but rather from the claims 

Claims 

50 

1. A method of optimizing a query having predi- 
cates applicable to attributes involved in the 
query, 

the method comprising the steps of: 

making a query graph for the query in 
which at least one node of the graph has a 
label with at least one predicate applicable to 
the attributes mentioned in the node; 



The foregoing "Detailed Description" has disclosed 
to those skilled in the art of optimizing queries how 55 
to perform optimizations in which predicates are 
first propagated in query graphs so that they oc- 
cupy positions which are advantageous for comput- 
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in a parent node of the graph, inferring a 
first new predicate in the parent node's label 
from a predicate in a label belonging to any 
child node of the parent; 

in a child node of the graph, inferring a 
second new predicate in the child node's label 
from a predicate in a label belonging to any 
parent of the node; and 

generating an optimized query from the 
query graph. 

2. The method set forth in claim 1 further com- 
prising the step of: 

reducing the number of the predicates in 
the query graph. 

3. The method set forth in claim 2 wherein the 
step of reducing comprises the step of: 

removing any predicate from a given 
node's label which is applied at a descendant 
of the given node. 

4. The method set forth in either claim 2 or claim 
3 wherein the step of reducing comprises the 
step of: 

removing any predicate in a label which is 
implied by another predicate in the label. 

5. The method set forth in either claim 1 or claim 
2 wherein: 

the step of inferring a first new predicate in 
the parent node's label is repeatedly per- 
formed beginning with a child node which Is a 
leaf node and ending when the parent node 
has no parent; and 

the step of inferring a second new predi- 
cate in the child node's label is repeatedly 
performed beginning with a parent node which 
has no parent and ending when the child node 
is a leaf node. 

6. The method set forth in either claim 1 or claim 
2 wherein: 

each node of the query graph represents a 
computation in the query; 

the predicate used to infer the first new 
predicate is a predicate on an exported at- 
tribute, the exported attribute appearing in the 
result of the computation represented by the 
child node; and 

the predicate used to infer the second new 
predicate is a predicate on an exported at- 
tribute. 

7. The method set forth in claim 6 wherein the 
step of inferring the first new predicate from 
the predicate on the exported attribute com- 
prises: 



applying the predicate on the exported at- 
tribute to a local attribute local to the node 
which corresponds to the exported attribute. 

5 8. The method set forth in claim 6 wherein the 
step of inferring the second new predicate 
from the predicate on the exported attribute 
comprises: 

applying the predicate on the exported at- 
io tribute to a local attribute local to the node 

which corresponds to the exported attribute. 

9. The method set forth in claim 1 or claim 2 
further comprising the step performed in the 

w parent node of: 

adding a third new predicate which is im- 
plied by predicates in the label. 

10. The method set forth in either claim 1 or claim 
20 2 wherein the step of making a query graph 

further comprises the step of: 

inferring a predicate from a function on an 
attribute of a base relation. 

25 11. The method set forth in claim 1 or claim 2 
further comprising the step performed in the 
child node of: 

adding a fourth new predicate which is 
implied by predicates in the label. 

30 

12. A method of optimizing a query having predi- 
cates applicable to attributes involved in the 
query, 

the method comprising the steps of: 
35 making a query graph for the query in 

which at least one node of the graph has a 
label with at least one predicate applicable to 
the attributes mentioned in the node; 

reducing the number of predicates in the 
40 query graph; and 

generating an optimized query from the 
query graph. 

13. The method set forth in claim 2 or claim 12 
45 wherein: 

the step of reducing the number of the 
predicates reduces the predicates such that no 
predicate is applied more than once. 

so 14. The method set forth in claim 12 wherein the 
step of reducing comprises the step of: 

removing any predicate from a given 
node's label which is applied at a descendant 
of the given node. 

55 

15. The method set forth in either claim 12 or 
claim 14 wherein the step of reducing com- 
prises the step of: 
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removing any predicate in a label which is 
implied by another predicate in the label. 

16. A method of optimizing a query which has 
predicates applicable to attributes involved in 5 
the query and which includes an aggregation 
operation, the method comprising the steps of: 

making a query graph for the query in 
which at least one node of the graph has a 
label with at least one predicate applicable to jo 
the attributes mentioned in the node; 

inferring a new predicate involving the ag- 
gregation operation and adding the new predi- 
cate to the label; 

moving the new predicate in the graph ?s 
such that the aggregation operation is limited; 
and 

generating an optimized query from the 
query graph. 

20 

17. A method of optimizing a query which has 
predicates applicable to attributes involved in 
the query, the predicates including predicates 
involving results of functions on base relations, 

the method comprising the steps of: 25 

making a query graph for the query in 
which at least one node of the graph has a 
label with at least one predicate applicable to 
the attributes mentioned in the node; 

inferring a new predicate involving the re- 30 
suits of the functions and adding the new 
predicate to the label; 

moving the new predicate in the graph 
such that the new predicate will be applied 
more efficiently than otherwise in calculating 35 
the query; and 

generating an optimized query from the 
query graph. 



45 
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FIG. 1 



calls(FromAC, FromTel, ToAC, ToTel, AccessCode, StartTime, Length)'] 
customers(AC, Tel, OwnerName, Type, MemLevel) / 
users(AC, Tel, UserName, AccessCode) / 
secret(AC, Tel) 

promotion(AC, SponsorName, StartingDate, EndingDate) 

(£1): CREATE VIEW fgAccounts(AC, Tel, UserName) AS 

SELECT DISTINCT c.AC, c.Tel, u.UserName ^ 
FROM customers c, users u V. 109 

WHERE c.AC = u.AC AND 

c.Tel = u.Tel AND 

c.Type = "Govt" AND 

c.AC = "Oil" AND 

NOT EXISTS (SELECT * FROM secret s 

WHERE s.AC = c.AC AND s.Tel = c.Tel) y 

(Fl): CREATE VIEW ptCustomers (AC, Tel, OwnerName, ToAC, MaxLen) AS> 
SELECT c.AC, c.Tel, cOwnerName, t.ToAC,)MAX (t.Length). 
FROM customers c, calls t / y 

WHERE t.Length > 2 AND ( 



t.FromAC <> t.ToAC AND \\\ 

c.AC = t.FromAC AND 
c.Tel = t.FromTel AND 
c.MemLevel — "Silver" 
GROUPBY c.AC, c.Tel, cOwnerName, t.ToAC 



109 



>105 



109 



(Ql): SELECT ptc.AC, ptc.Tel, fg.UserName, p.SponsorName > 
FROM ptCustomers ptc, fgAccounts fg, promotion p 
WHERE ptc.AC = f g.AC AND 

ptc.Tel = fg.Tel AND 

ptc.MaxLen > 50 AND 

p.AC = ptc.ToAC 



'/* <> is the SQL symbol for not equal */ 
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FIG. 2 



(El 0 ): CREATE VIEW f gAccounts 0 (AC, Tel, UserName) AS 
SELECT DISTINCT c.AC, c.Tel, ii.UserName 
FROM customers c, users u 
WHERE c.AC = u.AC AND 

c.Tel = u.Tel AND 

cType = "Govt" AND 

cMemLevel = "Silver" AND 

c.AC = "Oil" AND 

NOT EXISTS (SELECT + FROM secret s 

WHERE s.AC = <i.AC AND s.Tel = c.Tel) 

(Fl 0 ): CREATE VIEW ptCustoners 0 (AC, Tel, OwnerName, ToAC, MaxLen) AS*> 
SELECT c.AC, c.Tel, c.OwnerName, t.ToAC, MAX (t. Length) 
FROM customers c, calls t 
WHERE t.Length > 50 AND 

t.ToAC <> "Oil" AND 

t.FromAC = "Oil" AND 

c.Tel = t.FromTel AND 

cMemLevel = "Silver" AND 

cType = "Govt" AND 

c.AC = "Oil" AND 

NOT EXISTS (SELECT * FROM secret s 

WHERE s.AC = c.AC AND s.Tel = c.Tel) 
GROUPBY c.AC, c.Tel, c.OwnerName, t.ToAC 

{Ql 0 ): SELECT ptcAC, ptc.Tel, f g.UserName, p.SponsorName \ 
FROM ptCustoners,, ptc, f gAccounts 0 fg, promotion p I 
WHERE ptcAC = f g.AC AND > 207 

ptc.Tel = fg.Tel AND 

p. AC = ptc.ToAC J 
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FIG. 3 



CREATE VIEW V (Al, .... Al) 
SELECT r.B, 8.C, Kax(r.D) 
FROM R r, S 8 
WHERE r.B < r.C 

a. Or. A 
GROUPBY r.A 
HAVIHG ... 



,307 



Hax(r.D) 
GROUPBT r.A 



r.B < r.C 
s.C-r.A 



301 



FIG. 5 



509 ^ 
519v 



ptc.ToAC = p.AC fgACa-Ml" J 

StSFTt,:* NOTs.cr.UfgAQlk.W) U()9 

ptc.T«l = fa. Tel U(fJ.AC,tg.Td)- H Govt"J 

jlt^MwtLM « (Jlpl^C ptc.Td, ptcOwutrName, ptc.ToAC) 
r_HptcAC.ptc.Tcl) " 





FIG. 7 

calls(PromAC, FromTel, ToAC, ToTel, AccessCode, ) 

StartTime, Length) J 1Vi 

custoaers(AC, Tel, OwnerName, Type, MemLevel)-«v 
users( AC, Tel, UserName, AccessCode) --v ^" 705 

secret(AC, Tel)-— -709 707 
promotion(AC, SponsorName, StartingDate, EndingDate)»-^" 
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FIG. 6 



.ptc.ToAC « p. AC feAC«"*U H 

,ptc.Tel * £s.T«l t_l<fgAC,fjg.TeJ)«"Go*" 



i f.^pttAC, pIcTd, ptcOwneiName, plc.TcAC) 
Y_2(ptcJlC, ptcTel) « "SUwr" 




SELECT 
- • T.FromAC* "Oil'"— 
c.MemLevel => "Silver* 
c. length > 2 ^-fiOQ 

c.Tel * t.FrosTel 
c.Typo = i_l(c.AC. c.Tel) 
c.HeaLev.l = £_2(c.AC, c.Tal! 

• LLenslh > 50 
*cACT* m Oir „ 

• NOT secrete AC, c.Td) 
*c.Typ* = 'G<Ht" 




c.Tel « u.Tel 
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